Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PR: Add CI with github #100

Merged
merged 1 commit into from
Jul 27, 2020
Merged

Conversation

goanpeca
Copy link
Member

No description provided.

strategy:
fail-fast: false
matrix:
PYTHON_VERSION: ['3.5', '3.6', '3.8']
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like they've already got 3.9: probably better to know sooner! Heck I'd throw at least an pypy in there, too!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, will add it!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

at which point, is 3.6 even going to tell you much more than 3.5 until EOL in september?

jobs:
linux:
name: Linux py${{ matrix.PYTHON_VERSION }} tests
runs-on: ubuntu-latest
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

baby steps, I know, but windows (and to a lesser extent, osx) is where the real problems usually occur.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OSX build machines are "expensive" So maybe on OSX we should only run oldest and newest?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

too true, everything has a cost! i think as long as there is some coverage on all the platforms, it's solid. another thing i've done before, when the wall-clock time isn't as important as the overall resource footprint, is do strongest and weakest indicator builds by themselves (in this case, I guess that would be windows 3.5 and and linux 3.8?) and then open up the matrix, but still set a max concurrency.

- name: Install python dependencies
run: |
pip install setuptools pip --upgrade
pip install -v -e ".[test]"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems fine for now... though while running through it, I was a little surprised that the jupyter_server code paths aren't executed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤷

@goanpeca
Copy link
Member Author

Thanks @bollwyvl !

It's annoying that only after merged (unless I pushed to the repo directly) I can't really know if things are working as expected, so I would rather get this merged and I can iterate on improvements on the subsequent PRs where I can see the actual changes run :-p

@bollwyvl
Copy link
Contributor

I can't really know if things are working

Yeah, right? I've been opening up PRs against my fork's master when trying to do CI grunt work.

Even worse are the some of the events like status reacting to another CI's webhook: those only run from master, so it's really hard to debug them.

@blink1073
Copy link
Contributor

Is this ready to merge?

@goanpeca
Copy link
Member Author

goanpeca commented Jul 27, 2020

I think so @blink1073 I can iterate on this further once it is merged.

@blink1073
Copy link
Contributor

Cool, thanks!

@blink1073 blink1073 merged commit ee173a9 into jupyterlab:master Jul 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants